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Abstract.  Intelligent  systems  often  operate  in  a  blend  of  cyberspace 
and  physical  space.  Cyberspace  operations — planning,  actions,  and  ef¬ 
fects  in  realms  where  signals  affect  intelligent  systems — often  occur  in 
milliseconds  without  human  intervention.  Decisions  and  actions  in  cy¬ 
berspace  can  affect  physical  space,  particularly  in  SCADA — supervisory 
control  and  data  acquisition — systems.  For  critical  military  missions,  in¬ 
telligent  and  autonomous  systems  must  adhere  to  commander  intent  and 
operate  in  ways  that  assure  the  integrity  of  mission  operations.  This  pa¬ 
per  shows  how  policy,  expressed  using  an  access-control  logic,  serves  as  a 
bridge  between  commanders  and  implementers.  We  describe  an  access- 
control  logic  based  on  a  multi-agent  propositional  modal  logic,  show  how 
policies  are  described,  how  access  decisions  are  justified,  and  give  exam¬ 
ples  of  how  concepts  of  operations  are  analyzed.  Our  experience  is  policy- 
based  design  and  verification  is  within  the  reach  of  practicing  engineers. 
A  logical  approach  enables  engineers  to  think  precisely  about  the  secu¬ 
rity  and  integrity  of  their  systems  and  the  missions  they  support. 

Keywords:  policy,  concept  of  operations,  access  control,  logic. 


1  Introduction 

Cyber  space  and  physical  space  are  ever  more  intertwined.  Cyber-physical  sys¬ 
tems,  i.e. ,  systems  with  tight  coordination  between  computational  and  physical 
resources,  operate  in  these  intertwined  worlds.  Automatic  pilots  in  aircraft  and 
smart  weapons  are  examples  of  cyber-physical  systems  where  the  capability  to 
complete  Boyd’s  observe- orient- decide- act  decision  loop  [1]  in  milliseconds  with¬ 
out  human  intervention  is  essential. 

For  commanders,  fulfilling  the  missions  entrusted  to  them  is  of  paramount 
importance.  As  autonomous  cyber  and  cyber-physical  systems  have  by  their  very 
nature  little,  if  any,  human  supervision  in  their  decision  loops,  mission  assurance 
and  mission  integrity  concerns  require  that  the  trustworthiness  of  these  systems 
be  rigorously  established. 

A  practical  concern  is  how  commanders  and  implementers  will  communicate 
with  each  other.  Commanders  operate  at  the  level  of  policy:  what  is  permitted 
and  under  what  circumstances.  Implementers  are  concerned  with  mechanisms. 
Our  observation  is  that  commanders  and  implementers  communicate  through  de¬ 
scriptions  of  policy  and  concepts  of  operation.  Our  key  contribution  is  a  method¬ 
ology  for  describing  policies  and  trust  assumptions  within  the  context  of  concepts 
of  operations. 
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The  remainder  of  this  paper  is  organized  as  follows.  First,  we  informally  de¬ 
scribe  the  central  elements  of  policy  and  concepts  of  operation  that  we  wish  to 
describe  and  justify  rigorously.  Second,  we  describe  the  syntax  and  semantics  of 
our  access-control  logic.  Third,  we  describe  a  hypothetical  concept  of  operations, 
formalize  its  description,  and  provide  a  formal  justification  for  its  operations. 
Finally,  we  offer  summary  remarks  and  conclusions. 


2  Elements  of  Policy  and  Concepts  of  Operation 

Policies  are  principles,  guides,  contracts,  agreements,  or  statements  about  deci¬ 
sions,  actions,  authority,  delegation,  credentials,  or  representation.  Concepts  of 
operation  (CONOPS)  describe  a  system  from  the  user’s  perspective.  CONOPS 
describe  the  goals,  objectives,  policies,  responsibilities,  jurisdictions  of  various 
authorities,  and  operational  processes. 

The  elements  of  policy  we  are  concerned  with  include: 

—  who  or  what  has  control  over  an  action  and  under  what  circumstances, 

—  what  are  recognized  tokens  of  authority, 

—  who  are  recognized  delegates, 

—  what  credentials  are  recognized, 

—  what  authorities  are  recognized  and  on  what  are  they  trusted,  and 

—  any  trust  assumptions  used  in  making  decisions  or  judgments. 

We  conceptualize  CONOPS  as  a  chain  of  statements  or  requests  for  action.  These 
requests  are  granted  or  rejected  based  on  the  elements  of  policy  listed  above. 
This  is  illustrated  in  Figure  1.  What  Figure  1  shows  is  an  abstract  depiction  of  a 
CONOPS  that  has  three  or  more  principals  or  agents:  PI,  P2,  and  P3.  Principals 
are  entities  such  as  subjects,  objects,  keys,  tokens,  processes,  etc.  Principals  are 
anything  or  anybody  that  makes  requests,  is  acted  upon,  or  is  used  as  a  token 
representing  a  principal. 

CONOPS  begin  with  a  statement  or  request  si  by  PL  In  the  syntax  of  the 
access-control  logic  we  introduce  next,  this  is  the  formula  PI  says  si.  Principal 
P2 ,  is  envisioned  to  receive  the  statement  PI  says  si,  and  within  the  context  of 
jurisdiction  statements,  policy  statements,  and  trust  assumptions,  P2  concludes 
s2  is  justified.  As  a  result  of  this  justification,  principal  P2  transmits  a  statement 
P2  says  s2  to  principal  P3,  who  then  reacts  within  the  context  of  its  jurisdiction 
and  policy  statements,  and  trust  assumptions.  We  repeat  this  for  all  principals 
and  processes  in  the  CONOPS. 

Within  the  boxes  labeled  Principal  2  and  Principal  3  are  expressions 


PI  says  si 


PrinciDal  2 

PrinciDal  3 

PI  says  si 

Jurisdiction  statements 

, - \ 

P2  says  s2 

Jurisdiction  statements 

Policy  statements 

Trust  assumptions 

P2  says  s2  } 

Policy  statements 

Trust  assumptions 

s2 

s3 

P3  says  s3 


Fig.  1.  Concept  of  Operations 
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PI  says  si  P 2  says  s2 

Jurisdiction  statements  Jurisdiction  statements 

Policy  statements  Policy  statements 

Trust  assumptions  Trust  assumptions 

- sT- -  and  - s3  - ' 

What  the  above  expressions  intend  to  convey  is  that  based  on:  (1)  the  statements 
or  requests  si  and  s2  made  by  principals  PI  and  P 2,  and  (2)  the  statements 
of  jurisdiction,  policy,  and  trust  assumptions  under  which  principals  P 2  and 
P3  operate,  P2  and  P 3  are  logically  justified  (using  the  logic  and  calculus  we 
describe  next)  to  conclude  s2  and  s3.  As  we  will  see  after  formally  describing 
the  syntax  and  semantics  of  our  logic,  the  two  expressions  above  have  the  form 
of  derived  inference  rules  or  theorems  in  our  calculus.  Each  step  of  a  CONOPS 
expressed  in  this  fashion  is  a  theorem  justifying  the  behavior  of  a  system. 

One  of  the  principal  values  of  using  the  access-control  logic  is  the  evaluation 
of  a  CONOPS  for  logical  consistency  within  the  context  of  given  policies,  cer¬ 
tifications,  and  trust  assumptions.  The  process  we  outline  here  makes  explicit 
underlying  assumptions  and  potential  vulnerabilities.  This  leads  to  a  deeper  un¬ 
derstanding  of  the  underpinnings  of  security  and  integrity  for  a  system.  This 
greater  understanding  and  precision,  when  compared  to  informal  descriptions, 
produces  more  informed  design  decisions  and  trade-offs. 

In  the  following  section,  we  define  the  syntax  and  semantics  of  the  access- 
control  logic  and  calculus. 

3  An  Access-Control  Logic  and  Calculus 

3.1  Syntax 

Principal  Expressions.  Let  P  and  Q  range  over  a  collection  of  principal  expres¬ 
sions.  Let  A  range  over  a  countable  set  of  simple  principal  names.  The  abstract 
syntax  of  principal  expressions  is: 

P  ■■.=  A  I  PhQ  j  P\Q 

The  principal  P&Q  (“P  in  conjunction  with  Q”)  is  an  abstract  principal  making 
exactly  those  statements  made  by  both  P  and  Q\  P  \  Q  (“P  quoting  Q”)  is  an 
abstract  principal  corresponding  to  principal  P  quoting  principal  Q. 

Access  Control  Statements.  The  abstract  syntax  of  statements  (ranged  over  by 
p)  is  defined  as  follows,  where  P  and  Q  range  over  principal  expressions  and  p 
ranges  over  a  countable  set  of  propositional  variables: 

ip  ::=  p  /  ->p  /  pi  A  p2  /  Pi  V  p2  /  Pi  D  Pi  /  Pi  =  Pi  / 

P  =>  Q  /  P  says  <p  /  P  controls  p  /  P  reps  Q  on  p 

Informally,  a  formula  P  =>  Q  (pronounced  “P  speaks  for  Q”)  indicates  that 
every  statement  made  by  P  can  also  be  viewed  as  a  statement  from  Q.  A  formula 
P  controls  p  is  syntactic  sugar  for  the  implication  (P  says  p)  D  p:  in  effect,  P  is 
a  trusted  authority  with  respect  to  the  statement  p.  P  reps  Q  on  p  denotes  that 
P  is  Q' s  delegate  on  p\  it  is  syntactic  sugar  for  (P  says  ( Q  says  p))  D  Q  says  p. 
Notice  that  the  definition  of  P  reps  Q  on  p  is  a  special  case  of  controls  and  in 
effect  asserts  that  P  is  a  trusted  authority  with  respect  to  Q  saying  p. 
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£m\p\  =  i(p) 

£m  [“'¥>]  =  w  -  SmIvI 
£m  [vi  a  ^2]  =  £ m  [vil  n  £m  [V2J 

£m  [vi  v  ^2]  =  £ M  [¥>l]  U  £M  [¥2] 

£m\vi  3  ¥2]  =  (w  -  £m\vi\)  u  £m\v 2I 
£mIv>\  =  ¥2]  =  CmI^i  3  ¥>2!  n  £mIv 2  3  ¥>1] 


r  IV 

=>•  Q]  = 


if  J(Q)  C  J(P) 
otherwise 


£m\P  says  p>\  =  {ui|  J(P)(w)  C  fjn[¥>]} 
£m[P  controls  yj]  =  £m[(P  says  y?)  3  ip] 

£ M  [P  reps  Q  on  <p]  =  £ m  [P  |  Q  says  (p  3  Q  says  ip\ 


Fig.  2.  Semantics 


3.2  Semantics 

Kripke  structures  define  the  semantics  of  formulas. 

Definition  1.  A  Kripke  structure  A4  is  a  three-tuple  (W,I,J),  where: 

—  W  is  a  nonempty  set,  whose  elements  are  called  worlds. 

—  I  :  PropVar  — >  V(W)  is  an  interpretation  function  that  maps  each  propo¬ 
sitional  variable  p  to  a  set  of  worlds. 

—  J  :  PName  — »  V(W  x  W)  is  a  function  that  maps  each  principal  name  A 
to  a  relation  on  worlds  (i.e.,  a  subset  ofW  x  W). 

We  extend  J  to  work  over  arbitrary  principal  expressions  using  set  union  and 
relational  composition  as  follows: 

J(P&Q)  =  J(P)  U  J(Q) 

J(P  I  Q)  =  J(P)°J(Q), 


where 

J(P)  o  J(Q)  =  {{w\,w2)  |  w')  G  J(P)  and  (wr  ,w2)  G  J(Q)} 


Definition  2.  Each  Kripke  structure  A4  =  (W,I,J)  gives  rise  to  a  function 

eM\-\  ■ Form  -7W, 

where  the  se t  of  worlds  in  which  ip  is  considered  true.  is  defined 

inductively  on  the  structure  of  <p,  as  shown  in  Figure  2. 

Note  that,  in  the  definition  of  £m  [P  says  ip\ ,  J (P)  ( w )  is  simply  the  image  of 
world  w  under  the  relation  J{P). 

3.3  Inference  Rules 

In  practice,  relying  on  the  Kripke  semantics  alone  to  reason  about  policies, 
CONOPS,  and  behavior  is  inconvenient.  Instead,  inference  rules  are  used  to 
manipulate  formulas  in  the  logic.  All  logical  rules  must  be  sound  to  maintain 
consistency. 
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Taut 


if  p  is  an  instance  of  a  prop- 
logic  tautology 


Modus  Ponens 
MP  Says 


p  p  D  p' 


Says 


P  says  p 


(P  says  (p  D  p'))  D  (P  says  p  D  P  says  p') 
Speaks  For 


Quoting 


P  =>  Q  D  (P  says  p  D  Q  says  p) 


P  |  Q  says  p  =  P  says  Q  says  p 


SzSays 


Idempotency  of  - 


P&zQ  says  p  =  P  says  p  A  Q  says  p 

P'  =>  P  Q'  =>-  Q 


P  P 


Monotonicity  of  \ 


P'\Q'=>P\Q 


Associativity  of  \ 


P  I  (Q  I  -R)  says  y 
(P  |  Q)  |  it  says  ip 


P  controls  </?  —  (P  says  </?)  D 

P  reps  Q  on  p  P  |  Q  says  p  D  Q  says  p 

Fig.  3.  Core  Inference  Rules 


Quoting  (1) 


P  |  Q  says  p 
P  says  Q  says  p 


Quoting  (2) 


P  says  Q  says  p 


P  controls  p  P  says  p 

Controls  -  Derived  Speaks  For 


P  |  Q  says  p 

P  =>  Q  P  says  p 


Reps 


p  ‘  Q  says  p 

Q  controls  p  P  reps  Q  on  p  P  |  Q  says  p 


Rep  Says 


P  reps  Q  on  p  P  |  Q  says  p 


Q  says  p 

Fig.  4.  Derived  Rules  Used  in  this  Paper 


H  •  •  •  H 

Definition  3.  A  rule  of  form  - — - -  is  sound  if  for  all  Kripke  structures 

M  =  (i V,  /,  J),  if  Em  [-f /»]  =  W  for  each  i  e  {1, . . . ,  n},  then  Em  [C]  =  W. 

The  rules  in  Figures  3  and  4  are  all  sound.  As  an  additional  check,  the  logic 
and  rules  have  been  implemented  in  the  HOL-4  (Higher  Order  Logic)  theorem 
prover  as  a  conservative  extension  of  the  HOL  logic  [2] . 


3.4  Confidentiality  and  Integrity  Policies 

Confidentiality  and  integrity  policies  such  as  Bell-LaPadula  [3]  and  Biba’s  Strict 
Integrity  policy  [4],  depend  on  classifying,  i.e. ,  assigning  a  confidentiality  or 
integrity  level  to  information,  subjects,  and  objects.  It  is  straightforward  to 
extend  the  access-control  logic  to  include  confidentiality,  integrity,  or  availability 
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levels  as  needed.  In  what  follows,  we  show  how  the  syntax  and  semantics  of 
integrity  levels  are  added  to  the  core  access-control  logic.  The  same  process  is 
used  for  levels  used  for  confidentiality  and  availability. 

Syntax.  The  first  step  is  to  introduce  syntax  for  describing  and  comparing  secu¬ 
rity  levels.  IntLabel  is  the  collection  of  simple  integrity  labels ,  which  are  used 
as  names  for  the  integrity  levels  (e.g.,  hi  and  lo). 

Often,  we  refer  abstractly  to  a  principal  P’s  integrity  level.  We  define  the 
larger  set  IntLevel  of  all  possible  integrity-level  expressions: 

IntLevel  ::=  IntLabel  /  ilev(PName). 

A  integrity-level  expression  is  either  a  simple  integrity  label  or  an  expression  of 
the  form  ilev(A),  where  A  is  a  simple  principal  name.  Informally,  ilev(A)  refers 
to  the  integrity  level  of  principal  A. 

Finally,  we  extend  our  definition  of  well-formed  formulas  to  support  compar¬ 
isons  of  integrity  levels: 

Form  ::=  IntLevel  <,  IntLevel  /  IntLevel  =,  IntLevel 

Informally,  a  formula  such  as  LO  <t  il ev(Kat.e)  states  that  Kate’s  integrity  level 
is  greater  than  or  equal  to  the  integrity  level  LO.  Similarly,  a  formula  such  as 
il e\/(Barry)  =,  ilev(  Joe)  states  that  Barry  and  Joe  have  been  assigned  the  same 
integrity  level. 

Semantics.  Providing  formal  and  precise  meanings  for  the  newly  added  syntax 
requires  us  to  first  extend  our  Kripke  structures  with  additional  components 
that  describe  integrity  classification  levels.  Specifically,  we  introduce  extended 
Kripke  structures  of  the  form 

M  =  (W,I,J,K,L,A), 

where: 

—  W,  J,  and  J  are  as  defined  earlier. 

—  K  is  a  non-empty  set,  which  serves  as  the  universe  of  integrity  levels. 

—  L  :  (IntLabel  U  PName)  — >  K  is  a  function  that  maps  each  integrity  label 
and  each  simple  principal  name  to  a  integrity  level.  L  is  extended  to  work 
over  arbitrary  integrity-level  expressions,  as  follows: 

L{  ilev(A))  =  L(A), 

for  every  simple  principal  name  A. 

—  SC  K  x  K  is  a  partial  order  on  K:  that  is,  A  is  reflexive  (for  all  k  £  K , 
k  A  k),  transitive  (for  all  ki,k2,k^  €  K,  if  fci  A  fc2  and  fc2  A  k 3,  then 
ki  A  £3),  and  anti- symmetric  (for  all  fci,fc2  G  AT,  if  k\  A  /c2  and  fc2  A  k±, 
then  k\  =  fc2). 

Using  these  extended  Kripke  structures,  we  extend  the  semantics  for  our  new 
well- formed  expressions  as  follows: 

W,  if  L(£  1)  A  L(£2) 

0,  otherwise 

Sm\(-  1  =i  ^2]  =  SmI^I  ^2]  n£xp 2  <i  ^l]- 

As  these  definitions  suggest,  the  expression  =,  1 2  is  simply  syntactic  sugar  for 
(£ 1  <?:  £ 2 )  A  {£2  <i  £i)- 
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h  =i  =  (b  <i  (2)  A  (f2  <i  h 
RefLexivity  of  < 


Transitivity  of  <i 


<i  £ 

1  <i  ^2  £ 2  £3 

*1  <i  ^3 


Si  <i 


ilev(P)  =i  £\  ilev(Q)  =i  £i  £\  <i  £q, 


ilev(P)  <i  ilev(Q) 

Fig.  5.  Inference  rules  for  relating  integrity  levels 


Logical  Rules.  Based  on  the  extended  Kripke  semantics  we  introduce  logical 
rules  that  support  the  use  of  integrity  levels  to  reason  about  access  requests. 
Specifically,  the  definition,  rcflcxivity,  and  transitivity  rules  in  Figure  5  reflect 
that  <i  is  a  partial  order.  The  fourth  rule  is  derived  and  convenient  to  have. 


4  Expressing  Policy  Elements  in  the  Logic 

With  the  definition  of  the  syntax  and  semantics  of  access-control  logic,  we  pro¬ 
vide  an  introduction  to  expressing  key  elements  of  policy. 

Statements  and  requests.  Statements  and  requests  are  made  by  principals.  Re¬ 
quests  are  logical  statements.  For  example,  if  Alice  wants  to  read  file  foo,  we 
represent  Alice’s  request  as  Alice  says  (read,  foo).  We  interpret  (read,  foo)  as 
“it  would  be  advisable  to  read  file  /oo.” 

Credentials  or  certificates  are  statements,  usually  signed  with  a  cryptographic 
key.  For  example,  assume  we  believe  public  key  Kqa  is  the  key  used  by  certificate 
authority  CA.  With  this  belief,  we  would  interpret  a  statement  made  by  Kqa  to 
come  from  CA.  In  particular,  if  Kca  says  (K Alice  =>  Alice),  we  would  interpret 
this  public  key  certificate  signed  by  Kca  as  having  come  from  CA. 

Jurisdiction.  Jurisdiction  statements  identify  who  or  what  has  authority,  spe¬ 
cific  privileges,  powers,  or  rights.  In  the  logic,  jurisdiction  statements  usually 
are  controls  statements.  For  example,  if  Alice  has  the  right  to  read  file  foo ,  we 
say  Alice  controls  (read,  foo).  If  Alice  has  read  jurisdiction  on  foo  and  Alice  re¬ 
quests  to  read  foo,  then  the  Controls  inference  rule  in  Figure  4  allows  us  to  infer 
(read,  foo)  is  a  sound  decision,  i.e., 


Alice  controls  (read,  foo )  Alice  says  (read,  foo ) 

(read,  foo) . 

Controls  statements  are  also  statements  of  trust.  Suppose  CA  is  recognized  as  the 
trusted  authority  on  public-key  certificates.  If  CA  says  (K Alice  =>  Alice )  then  we 
believe  that  K Alice  is  Alice’s  public  key.  An  important  consideration  is  that  trust 
is  not  all  or  nothing  in  our  logic.  A  principal  may  be  trusted  on  some  things  but 
not  others.  For  example,  we  may  trust  CA  on  matters  related  to  Alice’s  key,  but 
we  may  not  trust  CA  on  saying  whether  Alice  has  write  permission  on  file  foo. 
Essentially,  the  scope  of  trust  of  a  principal  is  limited  to  the  specific  statements 
over  which  a  principal  has  control. 
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Proxies  and  delegates.  Often,  principals  who  are  the  sources  of  requests  or  state¬ 
ments,  clo  not  in  fact  make  the  statements  or  requests  themselves  to  the  guards 
protecting  a  resource.  Instead,  something  or  somebody  makes  the  request  on 
their  behalf.  For  example,  it  is  quite  common  for  cryptographic  keys  to  be  used 
as  proxies,  or  stand-ins,  for  principals.  In  the  case  of  certificate  authority  CA ,  we 
would  say  Kca  =>•  CA.  If  we  get  a  certificate  signed  using  Kca ,  then  we  would 
attribute  the  information  in  that  certificate  to  CA.  For  example,  using  the  De¬ 
rived  Speaks  For  rule  in  Figure  4  we  can  conclude  that  certificate  authority  CA 
vouches  for  K Alice  being  Alice’s  public  key: 

Kca  =►  CA  Kca  says  (KA iice  =>  Alice) 

CA  says  (K Alice  =£•  Alice). 

In  situations  where  delegates  are  relaying  orders  or  statements  from  their  su¬ 
periors,  we  typically  use  reps  formulas.  For  example,  say  Alice  is  Bob’s  delegate 
on  withdrawing  funds  from  account \  and  depositing  funds  into  account2-  If  we 
recognize  Alice  as  Bob’s  delegate,  we  would  write: 

Alice  reps  Bob  on  (( withdraw  $106,  account i)  A  (deposit  $106,  account2 )). 

From  the  semantics  of  reps,  if  we  recognize  Alice  as  Bob’s  delegate,  in  effect  we 
are  saying  that  Alice  is  trusted  on  Bob  stating  that  he  wishes  a  million  dollars  to 
be  withdrawn  from  accounti  and  deposited  into  account 2.  If  Alice  says  Bob  says 
withdraw  a  million  dollars  from  accounti  and  deposit  it  into  account2,  we  will 
conclude  that  Bob  has  made  the  request.  Using  the  Rep  Says  rule  in  Figure  4 
we  can  conclude: 

Alice  reps  Bob  on  (( withdraw  $106,  accounti)  A  { deposit  $106,  account2)) 

Alice  |  Bob  says  (( withdraw  $106,  accounti)  A  { deposit  $106 ,  account^)) 

Bob  says  (( withdraw  $106,  accounti)  A  ( deposit  $106,  account 2)). 


5  An  Extended  Example 

In  this  section  we  describe  a  hypothetical  example  CONOPS  for  joint  operations 
where  Joint  Terminal  Air  Controllers  (JTACs)  on  the  ground  identify  targets  and 
request  they  be  destroyed.  Requests  are  relayed  to  a  theater  command  author¬ 
ity  (TCA)  by  controllers  in  Airborne  Early  Warning  and  Control  (AEW&C) 
aircraft.  If  approved  by  commanders,  AEW&C  controllers  direct  aircraft  to  de¬ 
stroy  the  identified  target.  To  avoid  threats  due  to  compromised  communications 
and  control,  the  CONOPS  specifies  the  use  of  a  mission  validation  appliance 
(MVA)  to  authenticate  requests  and  orders.  What  follows  is  a  more  detailed 
informal  description  of  the  scenario  followed  by  a  formalization  and  analysis  of 
the  CONOPS. 

5.1  Scenario  Description 

The  sequence  of  requests  and  approvals  is  as  follows: 

1.  At  the  squad  level,  Joint  Terminal  Air  Controllers  (JTACs)  are  authorized 
to  request  air  strikes  against  enemy  targets  in  real  time. 

2.  Requests  are  relayed  to  theater  command  authorities  (TCAs)  by  Airborne 
Early  Warning  and  Control  (AEW&C)  controllers. 

3.  Requested  air  strikes  are  approved  by  TCAs.  These  commanders  are  geo¬ 
graphically  distant  from  the  squad  requesting  an  air  strike. 

4.  Command  and  control  is  provided  by  AEW&C  aircraft  operating  close  to 
the  squad  requesting  an  air  strike. 
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Threat  Avoidance.  For  mission  security  and  integrity,  JTACs,  AEW&C  con¬ 
trollers,  pilots,  and  TCAs  use  a  mission  validation  appliance  (MVA)  to  request, 
transmit,  authenticate,  and  authorize  air  strikes.  MVAs  are  envisioned  to  be 
used  as  follows: 

1.  JTACs  will  use  MVAs  to  transmit  air  strike  requests  to  AEW&C  controllers. 

2.  AEW&C  controllers  use  MVAs  to  (a)  authenticate  JTACs,  and  (b)  pass 
along  JTAC  requests  to  TCAs. 

3.  TCAs  use  MVAs  to  (a)  authenticate  JTACs  and  AEW&C  controllers,  and 
(b)  send  air  strike  authorizations  to  AEW&C  controllers. 

4.  AEW&C  controllers  use  MVAs  to  transmit  air  strike  orders  to  pilots. 

Security  and  Integrity  Requirements.  The  CONOPS  for  using  MVAs  must  meet 
the  following  security  and  integrity  requirements. 

—  All  requests,  commands,  and  approvals  must  be  authenticated.  No  voice 
communications  will  be  used.  This  includes  at  a  minimum: 

•  All  personnel  are  to  be  authenticated  into  mission  roles,  i.e. ,  joint  termi¬ 
nal  air  controller  (JTAC),  airborne  early  warning  and  controller  (AEW&C) 
controller,  pilot,  theater  command  authority  (TCA)  ,  and  security  officer 
(s°). 

•  All  communications,  commands,  and  approvals  are  to  be  encrypted  and 
signed  for  integrity. 

—  All  aircraft  pilots  receive  their  directions  from  AEW&C  controllers  and  can 
only  act  with  the  approval  of  the  TCA. 

—  All  keys,  certificates,  and  delegations,  i.e.,  the  foundation  for  trust,  must  be 
protected  from  corruption  during  operations.  Only  personnel  with  proper 
integrity  levels  are  allowed  to  establish  or  modify  the  foundation  of  trust. 

5.2  An  Example  CONOPS 

MVA  Use  Cases.  We  consider  two  use  cases.  The  first  use  case  shows  how  MVAs 
are  used  when  an  air  strike  is  requested  by  a  JTAC.  The  second  use  case  shows 
how  MVAs  are  used  when  a  TCA  orders  an  air  strike.  Figure  6  illustrates  the  flow 
of  requests  starting  from  Alice  as  JTAC,  through  Bob  as  Controller,  resulting  in 
an  authenticated  request  to  Carol  as  TCA.  The  process  starts  with  Alice  using 
her  token  Token  Alice  to  authenticate  herself  and  her  request  to  the  JTAC  MVA. 


Fig.  6.  Request  Use  Case 
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Table  1.  Requests  and  Relayed  Requests 


Statement 

Formal  Representation 

request  1 

(Token Alice  \  JTAC )  says  (strike,  target) 

relay  1 

( Kjtac-mva  \  JTAC )  says  (strike,  target) 

authenticated 
request  1 

JTAC  says  (strike, tar  get) 

request  2 

(TokenBob  |  Controller)  says  (JTAC  says  (strike,  tar  get)) 

relay  2 

(K controller- mva  \  Controller)  says  (JTAC  says  (strike, target)) 

authenticated 
request  2 

Controller  says  (JTAC  says  (strike, target)) 

Carol  Bob  Bob  Dan 


Fig.  7.  Order  Use  Case 
Table  2.  Orders  and  Relayed  Orders 


Statement 

Formal  Representation 

order  1 

(Tokencaroi  \  TCA)  says  (strike,  tar  get) 

relay  3 

(Ktca-mva  |  TCA)  says  (strike,  tar  get) 

authenticated 
order  1 

TCA  says  (strike,  target) 

order  2 

(TokenBob  \  Controller)  says  (TCA  says  (strike,  target)) 

relay  4 

(K controller -Mv a  |  Controller)  says  (TCA  says  (strike,  target)) 

authenticated 
order  2 

Controller  says  (TCA  says  (strike, tar  get)) 

The  JTAC  MVA  authenticates  Alice  and  her  role,  and  relays  Alice’s  request  using 
its  key,  Kjtac-mva  to  the  Controller  MVA.  The  Controller  MVA  authenticates 
the  JTAC  MVA  and  presents  the  authenticated  request  to  Bob. 

Should  Bob  decide  to  pass  on  Alice’s  request,  he  uses  his  token  to  authenticate 
himself  to  the  Controller  MVA,  which  relays  his  request  to  the  TCA  MVA,  which 
presents  the  authenticated  request  to  Carol,  a  Theater  Command  Authority. 
Table  1  lists  the  formal  representation  of  each  request,  relayed  request,  and 
authenticated  request  in  Figure  6. 

Figure  7  shows  a  similar  flow  of  orders  starting  from  Carol  as  TCA,  through 
Bob  as  Controller,  resulting  in  an  authenticated  order  to  Dan  as  Pilot.  Carol 
authenticates  herself  to  the  TCA  MCA  using  her  token.  Her  orders  are  relayed  to 
Bob.  When  Bob  decides  to  pass  on  the  order  to  Dan,  he  does  so  by  authenticating 
himself  to  the  Controller  MVA,  which  relays  to  orders  to  Dan  via  the  Pilot  MVA. 
The  formulation  of  each  order  and  relayed  order  is  shown  in  Table  2. 
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Person  Another  person 

Token  /  ^ 


^jRole  says  s] 
MVA2  I 


Fig.  8.  General  Pairing  of  MVAs 
Table  3.  Statements  and  Relayed  Statements 


Statement 

Formal  Representation 

statement 

( Token  \  Role)  says  p 

relayed  statement 

(Kmva-i  |  Role )  says  ip 

authenticated  statement 

Role  says  ip 

Deducing  Policies,  Certifications,  Delegations,  and  Trust  Assumptions.  Based 
on  the  use  cases  for  air  strike  requests  and  air  strike  orders,  we  determine  what 
policies,  certifications,  delegations,  and  trust  assumptions  are  required  to  justify 
each  MVA  action  in  the  CONOPS.  We  look  at  each  MVA’s  input  and  output, 
and  based  on  the  CONOPS,  infer  what  policies,  certifications,  delegations,  and 
trust  assumptions  are  required.  We  look  for  repeated  patterns  of  behavior  that 
lead  to  repeated  patterns  of  reasoning.  Both  use  cases  exhibit  the  same  pattern 
of  behavior  as  illustrated  in  Figure  8  and  formulated  in  Table  3. 

1.  A  person  authenticates  herself  and  claims  a  role  using  a  token.  Acting  in  a 
role,  the  person  makes  a  statement  (request  or  order).  The  first  MVA,  MVA 
1 ,  authenticates  both  the  person  and  the  role,  and  then  relays  the  statement 
using  its  key  to  the  second  MVA,  MVA  2. 

2.  MVA  2  authenticates  MVA  1  and  the  role  it  is  serving,  then  passes  the 
statement  up  to  the  person  using  MVA  2. 

Given  the  repeated  pattern,  we  prove  two  derived  inference  rules  ( MVA  1  and 
MVA  2)  that  justify  the  behavior  of  MVA  1  and  MVA  2. 


MVA  1 


(Token  \  Role )  says  p 
RAuth  says  ( Person  reps  Role  on  p) 
RAuth  says  (Token  =>  Person ) 
Auth  controls  (Person  reps  Role  on  p) 
Auth  controls  (Token  =>-  Person ) 

R Auth  Auth 

Rmva1  |  Role  says  p 


MVA  2 


( Rmva !  |  Role)  says  p 
Ra  uth  says  (MV A\  reps  Role  on  p) 
RAuth  says  (Rmva-l  =>  MV  Ax) 
Auth  controls  (MV A\  reps  Role  on  p) 
Auth  controls  (RmvAi  =>•  MV A\) 
RAuth  Auth 
Role  says  p 


Both  rules  have  the  same  components,  as  shown  in  Table  4.  The  components 
have  the  following  functions: 


11 


136 


S.-K.  Chin  et  al. 


Table  4.  MVA  Inputs,  Outputs,  Certificates,  Jurisdiction,  and  Trust  Assumptions 


Item 

Formula 

Input 

( Token  or  Key  \  Role)  says  ip 

Delegation  Certificate 

KAuth  says  ( Person  or  Object  reps  Role  on  ip) 

Key  Certificate 

KAuth  says  ( Token  or  Key  =t-  Person  or  Object) 

Jurisdiction 

Auth.  controls  ( Person  or  Object  reps  Role  on  ip) 

Jurisdiction 

Auth.  controls  ( Token  or  Key  =>  Person  or  Object) 

Trust  Assumption 

K-  Auth  Auth 

1.  input :  a  token  or  key  quoting  a  role 

2.  certificate:  a  certificate  authorizing  a  delegation 

3.  certificate:  a  public  key  certificate 

4.  jurisdiction:  an  assumption  about  an  authority’s  jurisdiction  to  authorize  a 
person  or  MVA  to  act  in  a  role 

5.  jurisdiction:  an  assumption  about  an  authority’s  jurisdiction  over  keys 

6.  trust  assumption:  knowledge  of  the  trusted  authority’s  key 

Both  rules  have  nearly  identical  proofs  that  are  direct  application  of  inference 
rules  described  in  Section  3.3. 

Using  the  inference  rule  MVA  1 ,  we  easily  prove  the  following  rule  for  the  TCA 
MVA  authenticating  Carol  and  validating  her  order  for  an  air  strike,  where  SO 
is  the  Security  Officer  role,  the  SO  has  jurisdiction  over  roles  and  keys,  and  K$ 
is  the  key  that  speaks  for  the  SO. 


TGA-MVA 


Tokencaroi  I  TCA  says  (strike,  tar  get) 

Kso  says  ( Carol  reps  TCA  on  (strike,  tar  get)) 
Kso  says  Tokencaroi  Carol 
SO  controls  Tokencaroi  Carol 
SO  controls  ( Carol  reps  TCA  on  (strike,  target )) 
Kso  =>•  SO 

Ktca-mva  |  TCA  says  (strike,  target) 


Similar  rules  and  proofs  are  written  for  each  MVA.  The  above  discussion  on 
certificates  installed  properly  in  MVAs  leads  us  to  the  final  use  case,  namely  the 
trust  establishment  use  case. 


5.3  Trust  Establishment 

Biba’s  Strict  Integrity  model  [4]  is  the  basis  for  maintaining  integrity  of  the 
MVAs.  As  Strict  Integrity  is  the  dual  of  Bell  and  LaPadula’s  confidentiality 
model  [3],  the  short  summary  of  Strict  Integrity  is,  no  read  down  and  no  write 
up.  For  subjects  S  and  objects  O,  S  may  have  discretionary  read  rights  on  O 
if  O’s  integrity  level  meets  or  exceeds  S’s.  For  write  access,  S’ s  integrity  level 
must  meet  or  exceed  O' s. 


ilev(S)  <i  ilev(O)  D  S  controls  (read,  O) 
ilev(O)  <i  ilev(S)  D  S  controls  {write,  O). 

There  are  two  integrity  levels:  Lop  and  where  Lop  <.,  Lgec.  All  certificates 
have  an  integrity  level  Lsea  he.,  ilev(cert)  =,  Lsec-  Table  5  show  the  integrity 
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Table  5.  Roles  and  Rights  to  Certificates 


Role 

Rights 

SO  (Lsec) 
JTAC  (Lop) 
Controller  ( Lop ) 
TCA  (Lop) 
Pilot  (L0p) 

install,  read 
read 
read 
read 
read 

level  and  certificate  access  rights  for  each  role.  Strict  integrity  is  satisfied  as  only 
the  security  officer  SO  (with  the  same  integrity  level  Lsec  as  certificates)  can 
install  or  write  certificates  into  MVAs.  Every  other  role  is  at  the  Lop  level  and 
can  only  read  certificates. 

Installing  Kso-  Establishing  the  basis  for  trust  in  MVAs  starts  with  the  installa¬ 
tion  of  the  Security  Officer’s  key,  Kso-  This  is  assumed  to  be  done  by  controlled 
physical  access  to  each  MVA  that  is  deployed.  Once  the  Security  Officer’s  key  is 
in  place,  the  certificates  that  an  MVA  needs  can  be  installed. 

Certificate  Installation.  Suppose  Erica  is  acting  as  the  Security  Officer  SO.  The 
policy  is  that  security  officers  can  install  certificates,  if  the  SO  has  a  high  enough 
integrity  level,  and  is  given  by 

ilev(cert)  <*  ilev(S'O)  D  SO  controls  (install ,  cert) . 

Erica’s  authorization  to  act  in  the  Security  Officer  role  to  install  certificates  is 
given  by 


Kso  says  Erica  reps  SO  on  (install ,  cert) . 

This  authorization  is  accepted  under  the  assumption  that  Kso  =>■  SO  and  that 
the  SO  has  jurisdiction,  which  is  given  by 

SO  controls  Erica  reps  SO  on  (install,  cert). 

The  proof  for  justifying  Erica’s  capability  to  install  certificates  acting  as  a  Secu¬ 
rity  Officer,  assuming  her  integrity  level  is  Lso  is  a  straightforward  application 
of  inference  rules  described  in  Section  3.3. 


6  Related  Work 

The  access-control  logic  we  use  is  based  on  Abadi  and  Plotkin’s  work  [5],  with 
modifications  described  in  [6].  Many  other  logical  systems  have  been  used  to 
reason  about  access  control.  Some  of  them  are  summarized  in  [7]. 

Our  contribution  is  the  methodology  and  application  of  logic  to  describe  poli¬ 
cies,  operations,  and  assumptions  in  CONOPS.  Moreover,  we  have  implemented 
this  logic  in  the  HOL-4  theorem  prover,  which  provides  both  an  independent 
verification  of  soundness  as  well  as  support  for  computer-assisted  reasoning. 
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7  Conclusions 

Our  objective  is  the  put  usable  mathematical  methods  into  the  hands  of  prac¬ 
ticing  engineers  to  help  them  reason  about  policies  and  concepts  of  operations. 
We  have  experimented  with  policy-based  design  and  verification  for  five  years 
in  the  US  Air  Force’s  Advanced  Course  in  Engineering  (ACE)  Cybersecurity 
Bootcamps  [8].  Our  experience  with  a  wide  variety  of  students,  practicing  engi¬ 
neers,  and  Air  Force  officers  suggests  that  using  the  access-control  logic  meets 
this  objective. 
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